home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000124_icon-group-sender _Thu Dec 10 09:33:34 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id JAA08163
  4.     for icon-group-addresses; Thu, 10 Dec 1998 09:32:04 -0700 (MST)
  5. Message-Id: <199812101632.JAA08163@baskerville.CS.Arizona.EDU>
  6. Date: Wed, 09 Dec 1998 20:03:16 -0600
  7. From: MJE <evans.nospam@gte.net>
  8. To: icon-group@optima.CS.Arizona.EDU
  9. Subject: Re: Formatting Reals
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12.  
  13. Everyone is picking me apart for my humble suggestion.  Clint likes it,
  14. that will be my consolation prize.  Let me move on.  It appears that we
  15. have a much more pressing need in Icon than a "past" keyword.
  16.  
  17. That is, intrinsic calls to format numbers.  I am trying to process
  18. spreadsheet data and am finding it impossible to get real numbers
  19. formatted without a lot of overhead in Icon.
  20.  
  21. Icon also fails to clarify whether internal reals are single or double. 
  22. I guess I'll have to examine the source.  If there is to be only one
  23. type of real, it should be double precision.
  24.  
  25. The Icon libraries for printf-like formatting are "printf" and "numbers"
  26. but both of them involve interpreted string scanning.  How silly:  A
  27. string scanning language that can't format numbers intrinsically.  All
  28. it would take is a direct pass-through to C library printf capability.
  29.  
  30. So it looks to me like Icon desperately needs some numeric formatting
  31. capability.  I can live without the "past" intrinsic, but I'll be in a
  32. rocking chair before my need for number formatting dies away.
  33.  
  34. Has anyone written a Windows DLL to give access to C's printf?
  35.  
  36. Mark
  37.  
  38.  
  39.  
  40.  
  41.  
  42. Richard A. O'Keefe wrote:
  43. > 
  44. >         What everyone is missing about procedures-that-do-the-job is the speed
  45. >         consideration.  Think about embedding either procedure in a deep inner
  46. >         loop of some kind.  At that point, it is much preferable to have a
  47. >         keyword, which
  48. > 
  49. >         (a) avoids any overhead of procedure calling,
  50. > 
  51. >         (b) doesn't have to both find and then match the same text
  52. >         (redundancy),
  53. > 
  54. >         (c) simplifies the code readability
  55. > 
  56. > Concerning (a), just what _is_ the procedure call overhead?
  57. > It's only worth worrying about if
  58. > (1) it is large compared with the useful work done (is it large?)
  59. > (2) the compiler is unable to expand calls to it in-line (is it unable?)
  60. > (3) there's nothing else going on in that loop with worse overheads.
  61. > 
  62. > Concerning (c), I note that realistic programming languages have to deal
  63. > with huge libraries these days.  Not the current UNIX interface (the
  64. > Single UNIX Specification one) but the _previous_ one was called Spec1170
  65. > because it had 1170 functions in the interface.  Windows has even more.
  66. > If procedure calls are unreadable, then heaven help us.
  67. > 
  68. > Concerning (b), is this the _only_ situation where that problem comes
  69. > up?  I don't think so.  Just how many keywords are we going to need if
  70. > we try to solve them all by keywords?
  71.  
  72.